A follow‑up PR will expose the client‑side pieces (see https://github.com/apache/httpcomponents-client/pull/762/changes).

@arturobernalg What is your plan? Do you want to provide the server side functionality out of the core project and the client side out of the client project? Should not the client protocol handler also go into core?

@arturobernalg What is your plan? Do you want to provide the server side functionality out of the core project and the client side out of the client project? Should not the client protocol handler also go into core?

@ok2c Plan is to keep server‑side WebSocket over H2 in core and client‑side in httpclient5. The client protocol handler is tied to the client execution stack and config, so it should stay in httpclient5. See apache/httpcomponents-client#762

@arturobernalg Interesting. How are you going to do integrations tests for the websocket protocol when it resides in two separate projects? The separation between core and client for HTTP protocol handlers is reasonably manageable: the message transport and the core protocol handling reside in core, advanced client functions reside in client. The core has integration tests that ensure correctness of the protocol handlers on both ends. in your case, I suspect the split into the server project and the client project will be hurting you in the long run. I do not know. This is your decision to make, but you may be better off having the server side websockets in the client project, at least for a few minor releases.

@arturobernalg Interesting. How are you going to do integrations tests for the websocket protocol when it resides in two separate projects? The separation between core and client for HTTP protocol handlers is reasonably manageable: the message transport and the core protocol handling reside in core, advanced client functions reside in client. The core has integration tests that ensure correctness of the protocol handlers on both ends. in your case, I suspect the split into the server project and the client project will be hurting you in the long run. I do not know. This is your decision to make, but you may be better off having the server side websockets in the client project, at least for a few minor releases.

@ok2c
moved the server‑side WebSocket classes and tests into httpclient5‑websocket as you suggested

@arturobernalg Wait. Again. Do you really want some WS primitives in a different project, so that every time you want something changed in those primitives you need a new release of core? Does that make sense?

Move everything WS related to client. Start low and simple. For your own sake reduce the public API footprint as much as possible. Gradually open it up as it matures, and at some point consider moving core protocol to core.

@arturobernalg Wait. Again. Do you really want some WS primitives in a different project, so that every time you want something changed in those primitives you need a new release of core? Does that make sense?

Move everything WS related to client. Start low and simple. For your own sake reduce the public API footprint as much as possible. Gradually open it up as it matures, and at some point consider moving core protocol to core.

@ok2c Okay. I'll do it gradually once the whole code is mature enough. I just move something related to WS

@arturobernalg Please update the commit message and the PR title.